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[57] ABSTRACT 

In a resilient database system which includes a journaled 
database which is implemented at one or more locations 
within a distributed data processing system, multiple diverse 
consistency levels are specified which each detail a level of 
consistency to be maintained between a primary database 
and a replica database. A user is then permitted to select a 
particular level of consistency for each replica database. 
Thereafter, each update to a record within the primary 
database is utilized to initiate an update to the corresponding 
record within each replica database in a manner which is 
consistent with the selected level of consistency for that 
replica database. In this manner, a replica database which is 
fully consistent with the primary database may be provided 
for seamless switchover in the event of a primary database 
failure, while a second replica database may be provided to 
respond to queries by applications which do not require fully 
consistent data, greatly enhancing the efficiency of access to 
that database. 

4 Claims, 10 Drawing Sheets 
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METHOD AND SYSTEM FOR SELECTABLE manager; (2) all application programs may be written to a 

CONSISTENCY LEVEL MAINTENANCE IN A single application programming interface and application 

RESILENT DATABASE SYSTEM programs need not be aware of data locations since all data 

BACKGROUND OF THE INVENTION 5 ablc t0 soWc mc piob[ems q{ adminjstcrirkg M& wi(hin a 

1. Technical Field centralized data environment; and (4) a single system is 
The present invention relates in general to an improved easier to operate, maintain and control. 

method for database access control and in particular to an However, there are certain disadvantages to a centralized 

improved method and system for maintaining consistency database approach which include: (1) communication costs 
between a primary database and one or more replica data- 10 are high for certain enterprises and application performance 

bases. Still more particularly, the present invention relates to may be degraded due to communication delays; (2) data 

an improved method and system for permitting a user to availability may be poor due to instability in the telepro- 

select diverse consistency levels to be imposed upon mul- cessing network or the central system, which may have to 

tiple replica databases within a resilient database system. mitigated by backup systems and redundant communication; 

2. Description of the Related Art 15 and (3) the processing capabilities of a single system have 
A multiprocessing general purpose computing system already been reached by some enterprises, 

typically includes a plurality of nodes which are intercon- T™ 0 general approaches exist for distributing data to 

nected by a communication network. Each node, in such a nodes of a distributed data processing system. These 

system, may include a data processor, a data storage device. approaches are (1) partitioning, and (2) static replication. In 
and multiple communication ports. A data processor may be 20 tne partitioned data approach mere is no primary copy of the 

executing, in a multiprogramming mode, under control of a database, whereas there may be in static replication, 

plurality of operating system components, and which event A partitioned database approach divides the database into 

the data processor may be considered a plurality of nodes. distinct partitions, and these partitions are then spread out 

The data storage device typically stores a data file, the among the nodes. A given data item resides at only one node 

operating system and its information management corapo- location. Each location has a database manager which man- 

nents and user application programs. ages the data at mat location. A data distribution manager 

Data is information which is abstracted from some aspect takes a data request from an application program and maps 

of business which is important to an enterprise. The chal- that request to a local request, if the data is held locally, or 
lenge within such systems is to utilize the data storage and ^ to a remote request if the data is held at another location, 

communication resources of the system in a manner which Good data availability and access performance result in a 

gives end users access to the data with an availability. partitioned distributed database if the data required is held 

performance and cost commensurate with their business locally. Furthermore, database integrity is facilitated since 

needs. Access to the data must be controlled to ensure the each data item is managed by a single database manager 

consistency and integrity of the data. Among additional These results may be achieved if a good partitioning algo- 

charactenstics of data accesses in a distributed data process- rithm exists, is known ahead of time and is stable 

ingenvkonment axe geographic and temporal affinity. to a partitioned database such as those described above. 

The basis for distributed data structures is geographic the system must provide a network-wide scope of recovery 

affimty: accesses to a given data item tend to duster geo- for programs which change data at more than one location 

a given data itemmaynotbe known ahead ctftime\ and th£ 45 JETS ,"1^ 

node may van- with time. upon dau locauon (3) changing the database partitioning 

tv.*mL«.a a. . u i . . algorithm is very difficult because data location is reflected 

init ftS^c T T V ? aUt S^ A f^" ln *• «PI*««itoo Programs, exits or declarations at each 

mgto the attributes of data location, degree of data sharing. node (4) existing data relocation and algorithm changes at 
degree to which daabase management control is provided so each node must be synchronized network-wide and therefore 

network-w.de. and to the type of data access. Datamation the partitioning algorithm may not be adjusted as nsSecl to 

may be centralize! partitioned or replicated. He degree of maintain optimum performance and availability; and (5) 

data sharing may be centralized, decentralized or distributed. programs which accWs data items uniformly across a par- 

J?!^? H7?T men, ( COntr ° 1 - J n i a ^ • 'V Mr pr ° Vided titioned database - <* must access the entire database, 
(d. tribute* data) or system prodded (distributed database). 55 will suffer poor performance and availability. 

ffJXSKF tranSaCU ° n *-*» „ repUcatioo technics for distributmg data indude 
u.-et~:~n., k ,■ ^ those which include or do not include a central node. In the 
iJEETELh ^ aPP T* h8S for former- *e central location stores a primary copy of the 
managing database storage and accesses. In such an database, and each location has a database manager and a 
ZE£L%y? management and application , processing « copy of the database. In typical uses of static replication, the 
are centralized. A single database manager is utilized and a primary database is copied and sent to each replica location, 
teleprocessing network is utilized to connect users to the or node, where the data becomes available for local pro- 
central facility. In a variation on the centralized approach. cessing. Dau modifications made at eachreplica locatio, [are 
^ e °i thc J^ OC "l ,n8 ^ < V StnbUted nodes coUected for later processing against the primary database, 
within the network; however, the data is kept centralized, a Between periods of W UcadoD processing, local mcW 
The advantages of a centralized database approach are: tions are sent to the central location and applied against the 
(1) database integrity may be ensured by the single database primary database. Because this technique for managing 
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replicated databases does nothing to prevent multiple 
updates, the occurrence of each such update must be 
detected during a primary database update and resolved 
manually, otherwise the application must be restricted so 
that somehow multiple updates do not occur. After the 
primary database has been made to conform to replica 
changes, new copies are sent to the replica locations and the 
entire process begins again. 

The main advantage of static replication with a primary 
copy at a central location is high availability and good 
response time since all data is locally accessible. However, 
significant disadvantages exist, including: (1) because the 
system does not prevent multiple updates, database integrity 
is difficult to ensure, severely restricting the database pro- 
cessing which is feasible for static replicas; (2) the system 
does not ensure current data for application access as 
requiring such; (3) special operational procedures are 
required for collecting and applying replica modifications to 
the primary database, which can be costly and prone to error; 
and (4) the database may not be available during the 
confirmation procedure, providing a large enough window 
for confirmation is not feasible in many applications since 
the data transmission bandwidth may be unnecessarily large 
between updates and replicas are transmitted only during the 
narrow window between periods of operation. Further, if one 
or more of node is incapacitated, then confirmation may not 
be possible in the scheduled window. 

Many variations have been described in the literature with 
respect to the basic techniques of static replication described 
above. The application can be designed so that multiple 
updates do not occur, or the replicas can be limited to read 
accesses only. The application program can collect updates 
itself for later transmission to the primary location, where 
this information may be gleaned from database manager 
logs. Full replicas or only partial replicas may be formed at 
the replica locations. The entire replica database or changes 
to data held can be transmitted. Replicas may be continually 
synchronized by sending modifications made by a transac- 
tion to the various nodes and receiving acknowledgements 
as a part of transaction termination processing. Such tech- 
niques of synchronization may solve the integrity problems 
of static replications; however, these techniques lose much 
of the performance and availability benefits of such systems. 

U.S. Pat No. 4,007,450, by Hiabt, describes a distributed 
data control system wherein each node shares certain of its 
data sets in common with other nodes, there being no 
primary copy of the central location, but replicas which are 
continually synchronized. Each node is operative to update 
any shared data set unless one of the other nodes is also 
seeking to update, in which event the node with the higher 
priority prevails. Each nodes stores in its memory the node 
location of each shared data set and the updating priority 
each node has with respect to each respective set of shared 
data. When a data set is updated at a node, all nodes having 
a replica are sent the update. As above, such a technique 
solves the integrity problem of static replication but loses 
much of the performance and availability benefits. 

VS. Pat. No. 4.432,057. issued to Daniell et al.; discloses 
a method for dynamic replication of data under distributed 
system control in order to control the utilization of resources 
in a multiprocessing, distributed database system. In this 
system requests for access to data of a specified concurrency 
are permitted and confirmation of updated data is selectively 
deferred by use of a control procedure which is implemented 
at each node, utilizing a status and control (SAC) message 
which is filed at each node which describes that node's view 
of the status for shared data items at other nodes. In this 



4 

system each database request must be intercepted to deter- 
mine if the local copy satisfies the concurrency require- 
ments. If not, negotiations with related nodes are required 
prior to granting the requests. The concurrency of replica 
5 databases will thus change dynamically according to the 
access patterns. 

In view of the above, it should be apparent that a need 
exists for a method and system for utilization in a resilient 
database system which includes a journaled database which 
10 is replicated at one or more locations within the data 
processing system whereby the consistency level maintained 
within each replica database may be arbitrarily and selec- 
tively assigned. 

13 SUMMARY OF THE INVENTION 

It is therefore one object of the present invention to 
provide an improved method for database access control 
within a distributed data processing system. 
20 ft is another object of the present invention to provide an 
improved method and system for maintaining consistency 
between a primary database and one or more replica data- 
bases within a distributed data processing system. 
It is yet another object of the present invention to provide 
25 an improved method and system for permitting a user to 
select diverse consistency levels to be imposed upon mul- 
tiple replica databases within a resilient database system in 
a distributed data processing system, 
The foregoing objects are achieved as is now described. 
30 In a resilient database system which includes a journaled 
database which is implemented at one or more locations 
within a distributed data processing system, multiple diverse 
consistency levels are specified which each detail a level of 
consistency to be maintained between a primary database 
35 and a replica database. A user is then permitted to select a 
particular level of consistency for each replica database. 
Thereafter, each update to a record within the primary 
database is utilized to initiate an update to the corresponding 
record within each replica database in a manner which is 
40 consistent with the selected level of consistency for that 
replica database. In this manner, a replica database which is 
fully consistent with the primary database may be provided 
for seamless switchover in the event of a primary database 
failure, while a second replica database may be provided to 
45 respond to queries by applications which do not require fully 
consistent data, greatly enhancing the efficiency of access to 
that database. 

The above as well as additional objects, features, and 
advantages of the present invention will become apparent in 
the following detailed written description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the invention 
55 are set forth in the appended claims. The invention itself 
however, as well as a preferred mode of use, further objects 
and advantages thereof, will best be understood by reference 
to the following detailed description of an illustrative 
embodiment when read in conjunction with the accompa- 
go nying drawings, wherein: 

FIG. 1 is a pictorial representation of a distributed data 
processing system which may be utilized to implement the 
method and system of the present invention; 
FIG 2 is a high level control flow for a typical write 
65 operation within a resilient database system implemented in 
accordance with the method and system of the present 
invention; 
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FIG. 3 is a high level logic flowchart which illustrates the data processing network 8 to access a database stored in 

establishment of multiple diverse consistency levels within another portion of data processing network 8. In such 

a resilient database in accordance with the method and client/server environments, access to data stored within a 

system of the present invention; and database may be increased by providing a so-called "resil- 

FIGS. 4-10 are a high level logic flow diagram which, 5 ient database system." A resilient database system is a 

when considered together, illustrate the implementation of journaled database thai is replicated at one or more locations 

multiple diverse consistency levels within a resilient data- within a distributed data processing system. Within such a 

base system in accordance with the method and system of database one database is designated as the primary database 

the present invention. while all others are backup replicas. A resilient database 

DETAILED DESCRIPTION OF PREFERRED w ^\ m . is resiU f 1 t to s j n S le P 0 ^ 5 of failure - T** is * a 

EMBODIMENT lS causcd b ^ a fiulurc or mc computer wherein one of 
„_. . , , the database replicas resides or a media failure which 
With reference now to the figures and in particular with damages one of the replicas. Ouster management can pro- 
reference to FIG. 1. there is depicted a pictorial represen- vide a recovery mechanism, transparent to both the appli- 
tation of a distributed data processing system 8 which may cation programmer and to the end-user, that allows a seam- 
be utilized to implement the method and system of the less switchover to a backup replica in the event of the failure 
present invention. As may be seen, distributed data process- of a primary replica 

ing system 8 may incline ajplurality of ^networks ^ such as ^ systcms in ^ a has ^cn replicated in 

t Area Networks (LAN) 10 and 32. each of which order t0 provide a ^ avaUa5flity of <,„ P a Mtul *l 

r^^l in ^f,~T ,er$ £ 20 cxtension^suchsystei^istopcrmitqucrycUeDtstouS 

and 30 respect.vdy. Of course, (hose skdled in die art will 20 a backup rq)Iica , 0 Aviate the workload on the 

S!^^^^ 1 ^^^^^ P rima ^ *™«* Howev «- unless *°™ insistency is 

Sofk. te UUU2ed f0f CaCh SUCh <l«ry transactions on the replica database would 

. . be permitted to read values set by uncommitted transactions. 

As is common is such data processing systems, each M as well as outdated values. While this may be acceptable for 

individual computer may be coupled to a storage device 14 some non-critical applications, many applications require a 

and/or a printer/output device 16. One or more such storage minimum level of consistency with respect to the Primary 

devices 14 may be utilized, in accordance with the method database 

l^ P ^ inV v *i 0n - t0 T K 3 ET^ <U,tabaSe ; ° r * For Pun*** ° f explanation within this application, the 

rephca thereof which may be periodically accessed and 3, ttrm Ration" refers to the application c^ wWch is 

system 8. in accordance with the mediod and system of the Many mereut applications are available wWchmay be 

32^£^£E uTZ*""* WS* axe unmodifiedin accordancS the method and ^emo 

^maintaining and update Abases associat^ere- ^^^Z^^^Z 

Still referring ,0 HG. 1. it may be seen that dieted S^S^SE T^^^s^ 
dau processing system 8 may also mclude multiple main- w agemcnt and thereafter ships the request to the maZe 

frame computers, such as mainframe computer 18. which which controls the primary database Any recovery steps 

rnayteprefenblyc^ledtol^AreaNe^cAa^W which m required ^euT a failure aKUdSTSLTE 

by means of communications link 22. Mainframe computer application by means of the application stub 

18 may also be coupled to a storage device 20 which may The '•primary agent" described within the present anuV 

serve as remote storage for Local Area Network CLAN^ 10 . F 7 ^ . w *^"i «<e present appii- 

A second Local Area Ltwork^^l rTy be co££d to 45 ^^ 'Z^^T ° D ? T'T ^ 

Local Area Network (LAN) 10 via conirrJnications con! g^jSST.^* '"'"V T*** °**™«™J^ 

troller 26 and communications link 34 to a gateway server ZZZF^tJ*?- T a H 5,lca «"> n ^ess. A "backup 

us n»,„„,^,, c^,-, •« —J TT j. J7 , receiver." as utilized in the present method and system, is a 

oTtoSt^S^W^wh^ht^! rTT^ P 100 " 5 on a which controls access to a 

. * , ' * la*^ «im nciwuiK ^lajnj iu. the changes which have been made to the primary database 

n TJ%T!^ , 1 7 'T 01 *Z ^ x^f NctWOrk and whi * deP°^ feose journal entries^*, a local 

£AN) 32 and Local Area Network (LAN) 10 primary replica of thermal. There is one backup receiver process 

^mISI^ ^ Wlthk T*' f ° r a 8 iveD A"*"" « rnacmnTwhic* conttoTa 

xf contro " e J? b V mainframe computer 18. as S5 replica of the database. A "backup applicr" is a process on 

Resource Manager or Library Service for the primary data- the machine which controls a replica database wWchl^lies 

wl^^wS ^ n Aejourr^entriestothelocalrephcaofthedaubase^ere 

Of course, those skilled in the art will appreciate that is one backup applier process for a given database on each 

maiiiframe computer 18 may be located a great geographical machine which controls a backup replica 

fr °M ^^A^T* ( t A ^ ) 19 aDd Stoflarly 60 RefttriB 8 now to nG 2- ">»e is illustrated a high level 

Local Area Network (LAN) 10 may be located a substantial control flow for a typical write operation within aresulent 

distar^ from L^aL^ea Network (LAN) 32. I^t is. Local database system which is implemented in accordance wii 

^"i^n ^ ^ "> CaHf ° rnia WhUe ^thod and system the present invention As 

Local Area Network (LAN) 10 may be located within Texas illustrated, a user 40 may utilize an appUcation 42 which 

and rnamframe computer 18 may be located in New York. 6S invokes a stub routine 44 to executed operation wZ 

Aswillbeappreaateduponreferencetotheforegoing.it primary database 46. The primary agent 48 within (he 

is often desirable for users within one portion of distributed machine which controls primary database 46 executes that 
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operation. Any journal entries required by that modification ting the user or system administrator to set various diverse 

are inserted within journal SO and are broadcast to the levels of consistency for replica databases within the resil- 

backup receiver 54 within replica database 52 and any ient database system of the present invention, two different 

additional replica databases, such as replica database 60. variables must be set in order to control the level of 

Backup receiver 54 acknowledges reception of these 5 consistency. Ordering may be set to either "Level 0," "Level 

journal entries and thereafter asynchronously deposits those 01 "Level 2 " Additionally, serializability must be set to 

entries within a local replica of that journal, such as illus- either "true" or "false." 

trated at reference numeral 58. Backup applier 56 applies the With reference now to FIG. 3. there is depicted a high 
journal entries contained within journal 58 to the corre- level logic flowchart which illustrates the establishment of 
sponding record within replica database 52 by locking that 10 multiple diverse consistency levels within a resilient data- 
record, updating the record and thereafter unlocking the base in accordance with the method and system of the 
record. In this manner, consistency between replica database present invention. As illustrated, this process begins at block 
52 and primary database 46 may be maintained. 70 and thereafter passes to block 72. Block 72 illustrates a 
Backup applier 56 thus provides a muiimal level of determination of whether or not a consistency level selection 
consistency by preventing readers from obtaining partially 15 nas occurred. If not, this process merely iterates until such 
updated records which might otherwise be obtained if those lira « s the user or system administrator indicates a desire to 
records were read directly from replica database 52. Of set me consistency level for a replica database within the 
course, the control flow for a database read operation is resilient database system, 

similar to that depicted within FIG. 2; however, no journal Still referring to block 72. in the event a consistency level 

entries are generated and therefore the backup receiver and 20 select has occurred, the process passes to block 74. Block 74 

backup applier are not involved. The environment depicted illustrates a process which will occur for the first replica 

within FIG. 2 may be implemented utilizing any suitable database within the resilient database system of the present 

computer system such as the International Business invention. Next, the process then passes to block 76. Block 

Machines Corporation Application System/400. 76 illustrates the prompting of the user/system operator for 

Next, in accordance with an important feature of the a desired consistency level. Thereafter, the process passes to 

present invention multiple diverse consistency levels are block 78. Block 78 illustrates a determination of whether or 

provided which may be selected by a user for utilization with not the consistency level desired has been entered and if not. 

a selected replica database. Concurrence within resilient the process returns, in an iterative fashion, to block 76, to 

database systems is discussed within "Concurrence Control ^ ODce again prompt the user to enter a desired consistency 

and Recovery in Database Systems*' Addison-Wesley Pub- level. 

lishing Company. 1987. which describes a multivcrsion Still referring to block 78, in the event a desired consis- 

concurrence control model. In that system the backup replica tency level has been entered, the process passes to block 80. 

database may always lag behind the primary, leading to the Block 80 illustrates a r^ornpting of the user/system operator 

existence of two versions of the database. In contrast to that 35 for a serializability requirement That is, an indication of 

system, the method and system of the present invention whether or not the interleaved execution of a transaction 

provide two different consistency properties which are taken must be logically equivalent to a serial execution. The 

into consideration. process then passes to block 82. Block 82 illustrates a 

Specifically, these two properties comprise the ordering of determination of whether or not the user has entered a 

transactions within the database system and the serializabil- ^ serializability requirement and if not. the process returns, in 

ity of those transactions. These two properties may be aD iterative fashion to block 80 to once again prompt the user 

combined in several ways, leading to six different consis- to enter a serializability requirement for that database, 

tency levels. Thus, in accordance with an important feature Thereafter, after the user has entered a serializability 

of the present invention, three different consistency levels requirement the process passes from block 82 to block 84. 

for ordering of transactions may be considered for queries 45 Block 84 illustrates a determination of whether or not 

which are reading from a replica database. Of course, those additional replica databases are to be set to one of a plurality 

skilled in the art will appreciate that a maximum time lag °f diverse consistency levels and, if the replica database 

may be specified for consistency following a record update. operated upon is not the last replica, the process returns, in 

A l *Level 0" consistency level permits queries to read old an iterative fashion, to block 76 to once again begin the 

values within the replica database. A "Level T consistency jq P 1000 ™ described herein. Alternately, in the event the last 

level imposes a consistency such that queries will read only replica database has had a desired consistency level selected, 

the latest committed values from the replica databases. the process passes to block 86 and returns. 

Finally, a ''Level 2" consistency level imposes a consistency Referring now to FIGS. 4-10. there are illustrated high 

level such that queries will read only the latest values from level logic flow diagrams which, when considered together, 

the replica database, whether or not those values have 55 illustrate the implementation of multiple diverse consistency 

reached a commit. levels within a resilient database system in accordance with 

Additionally, as described above, the serializability of me method and system of the present invention following a 

transactions within the resilient database system of the record update. As illustrated within FIG. 4, the process 

present invention must be considered in order to assign a begins at block 90. Thereafter, the process passes to block 92 

desired consistency level. This property guarantees that the 60 which depicts a determination of whether or not a record 

possibly interleaved execution of transactions is logically update has occurred. In the event no record update has 

equivalent to a serial execution of those transactions. A occurred, this process merely iterates until such time as a 

resilient database system permits applications under com- record update to the primary database occurs. Thereafter, 

mitment control to run simultaneously on the same database upon the occurrence of a record update, the process passes 

with other applications which are not under commitment 65 fr° m block 92 to block 94. 

control. It is therefore conceivable that different applications Block 94 illustrates the beginning of a process which is 

may or may not require serializability. Thus, when rjermit- reiterated for each replica database within the resilient 
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database system of the present invention. The process then action results in a third journal entry (JE3) which is trans- 
passes from block 94 to block 96. Block 96 illustrates a mitted to the backup receiver. The backup receiver again 
determination of whether or not the desired consistency sends an acknowledgement and deposits this journal entry 
level has been set to "Level 0," If so. the process passes to within the local journal. The backup applier then locks 
block 98. Block 98 illustrates a determination of whether or 5 record R3 and applies the journal entry (JE3). 
not serializability is required and if so. the process passes to Finally, reference numeral 156 depicts a commit opera- 
the logic flow described within FIG. 5. via off page con- tion for transaction Tl. This transaction results in a subse- 
nector 100. Alternately, in the event serializability is not quent journal entry (JE4) which is transmitted to the backup 
required, the process passes to the logic flow described at receiver. The backup receiver sends an acknowledgement to 
FIG. 6. via off page connector 102. iQ the primary database and deposits the journal entry (JE4) 
Referring again to block 96. in the event the desired within the local journal Hie backup applier then releases the 
consistency level is not set to "Level 0 " the process passes locks to records Rl and R3. 

to block 104. Block 104 illustrates a deterrnination of With reference now to FIG. 6. the logic flow which occurs 

whether or not the desired consistency level has been set to as a result of an update to a record within a replica database 

"Level 1." If so. the process passes from block 104 to block set to consistency "Level 0" with serializability not required. 

106 which once again illustrates a determination of whether For purposes of simplicity of explanation, the columns and 

or not serializability is required. If so. the process passes to transaction events within FIGS. 6-10 are numbered identi- 

the logic flow described at FIG. 7. via off page connector cally to those contained within FIG. 5. As above, the process 

108. Alternately, in the event serializability is not required. begins at reference numeral ISO which illustrates a transac- 

the process passes to the logic flow illustrated at FIG. 8, via ^ tion Tl which includes an update Ul to record Rl. This 

off page connector 110. transaction results in a journal entry (JE1) which is coupled 

Referring again to block 104. in the event the desired to the backup receiver. An acknowledgement is sent from the 

consistency level is not "Level 1," the process passes from backup receiver to the primary database and journal entry 

Wcckl04toblockll2.Blc)ckll2musD-atesadete3iriination (IE1) is deposited within the local journal. The backup 

of whether or not the desired consistency level for this 2$ applier then locks record Rl and applies the journal entry 

replica database is set to "Level 2" and if so. the process (JE1). Thereafter, the backup applier releases record Rl, 

passes from block 112 to block 114. As above, block 114 since serializability is not required 

illustrates a detemiiiauon of whether or not serializability is Referring now to reference numeral 152. transaction T2 is 

required and if so, the process passes to the logic flow illustrated which includes update U2 to record RZ This 

described within FIG. 9. via off page connector 116. transaction results in a journal entry (JE2) which is applied 

Alternately, in the event serializability is not required, the to the backup receiver which again sends an acknowledge- 

process passes from block 114 to the logic flow described ment to the primary database and deposits journal entry 

within FIG. 10 via off -page connector 118. Finally, referring (JE2) within the local journal. The backup applier then locks 

again to block 112. in the event the desired consistency level record R2, applies the journal entry JE2 and thereafter 

is not set to "Level 2" the process passes to block 120 and 35 releases record R2. 

rCt ^l ™ * ^ At refercncc numeral 154 an additional portion of trans- 

With reference now to FIG. 5, there is depicted the logic action Tl is illustrated which includes update U3 to record 

flow sequence which occurs in the event a record update has R3. This transaction results in a journal entry (JE3) which is 

(>ccurred to a record corresponding to a record within a transmitted to the backup receiver. The backup receiver then 
replrca database for which consistency level "Level 0" has m sends an acknowledgement to the primary database and 

been chosen, with serializability required. FIGS. 5-10 each deposits the journal entry (JE3) in the local journal The 

mclude four columns numbered respectively 130. 132. 134, backup applier then locks record R3. applies the journal 

and 136. In each instance column 130 illustrates the activity entry (JE3) and thereafter releases record R3 

S^JSS^J^ W k l COlUmD - 134 t C * 5 at refercncc ^nieral 156. This commit operation resets in 

achyities wtuch occur at the backup receiver wifhin the a journal cntry (rE4) which * transmitted to the backup 

5^£^t da S bas : u ^ cr ^ acknowledgement is transmit^ to £ pSS? 

Sl£ ? f h ^ ? r ° f baCkUP ^ (SCe to backup receiver and the journal entry^ 

FIG. 2) within the replica database. is within me local jouraaL As s J cliaJizaoih ^ [ s Q( £ 

Thus, examining column 130 of FIG. 5. a transaction Tl 50 required, the commit operation does not result in activity by 

is illustrated which includes update Ul to record Rl. as the backup applier 

fn^l ? Ute " ? ^ Ne3U < rcfeirifl S to FIG. 7, a logic flow is illustrated which 

en*y (JB1) which is transmitted to the backup receiver. Tie dcpicts mc „ vmm to m ^ to a record within me 

backup receiver then sends an acknowledgement to the pri^ database wherein a consistency level "Level r has 

p^ database and deposits Uie journal entry (ffil) witto 55 ^ wdkaeA for a ^ se riahzability is 

the load journal * :thc re^ca database. The teckup appUer requirc4 . A s above. Terence numeral 150 illustrates a 

then Jocks record Rl and applies the journal entry (JE1). transaction Tl which includes update Ul to record Rl. This 

Next, as illustrated at reference numeral 152, transaction transaction results in a journal entry (JE1) which is trans- 
it is depicted which includes update U2 to record R2. This mitted to the backup receiver. An acknowledgement is sent 
transaction results in a journal entry (JE2) which flows to the 60 by the backup receiver to the primary database and the 
backup receiver. The backup receiver then sends an journal entry (JE1) is deposited within the local journal. The 
acknowledgement to the primary database and deposits backup applier then stores this journal entry (JE1) in a 
journal entry (JE2) within the local journal. Thereafter, the buffer. Recalling that consistency level 'Level 1" imposes a 
backup applier locks record R2 and applies the journal entry requirement that queries may only read the latest committed 
V^ 2 )- 65 values, those skilled in the art will appreciate that the update 

Next, at reference numeral 154. transaction Tl is illus- to record Rl must necessarily be stored within a buffer until 

trated which includes update U3 to record R3. This trans- such time as a commit transaction has occurred. 
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Next, as illustrated at block 152. transaction T2 which database where consistency level "Level 2" is set with 

includes update U2 to record R2 occurs. This results in a serializability required. As above, reference numeral 150 

journal entry (JE2 ) which is coupled to the backup receiver. illustrates the occurrence of a transaction Tl which includes 

Hie backup receiver sends an acknowledgement to the update Ul to record Rl. This transaction results in a journal 

primary database and deposits the j ournal entry ( JE2) within 5 entry (JE1 ) which is transmitted to the backup receiver. The 

the local journal. As above, the backup applier then stores backup receiver then locks Rl and sends an acknowledge - 

this journal entry (JE2) within a buffer. ment to the primary database. The journal entry (JE1) is then 

Next, as illustrated at block 154, a transaction Tl which deposited within a local journal and the backup applier 

includes update U3 to record R3 occurs. This results in a immediately applies the journal entry (JE1). Those skilled in 

journal entry JE3 which is coupled to the backup receiver io the art will note that a consistency level "Level 2 M imposes 

As above, an acknowledgement is transmitted from the the requirement that queries read only the latest values, 

backup receiver to the primary database and the journal whether or not a commit has occurred. Thus, the update to 

entry (JE3) is deposited within a local journal. The backup record Rl will be immediately applied by the backup 

applier then stores this journal entry (JE3) within a buffer. applier. 

Finally, as depicted at block 156, a commit operation for 15 Referring now to block 152. a transaction T2 occurs 

transaction Tl occurs. This results in a journal entry (JE4) which includes update U2 to record R2 has occurred. This 

which is transmitted to the backup receiver. The backup results in a journal entry (JE2) which is coupled to the 

receiver locks records Rl and R3 and sends an acknowl- backup receiver. The backup receiver then locks the record 

edgement to the primary database. The backup applier then R2, sends an acknowledgement to the primary database and 

retrieves the journal entries from transaction Tl and applies 20 then deposits the journal entry (JE2) in the local journal. The 

the appropriate journal entries (JE1 and JE3). those journal backup applier then immediately applies the journal entry 

entries which are associated with transaction Tl. Thereafter, (JE2). updating the record R2 to the latest value, 

records Rl and R3 arc released. Thus, the updates to records Referring now to reference numeral 154, a second portion 

Rl and R3 are not applied by the backup applier until such of transaction Tl has occurred which includes an update U3 

time as a commit operation for that transaction occurs. 23 to record R3. This results in a journal entry (JE3) which is 

Referring now to FIG. 8 a logic flow is illustrated which then coupled to the backup receiver. The backup receiver 

describes the response to an updated record within a replica then locks record R3 and sends an acknowledgement to the 

database set to consistency level "Level 1" wherein serial- primary database. The journal entry (JE3) is then deposited 

izability is not required. As above, reference numeral 150 within the local journal and the backup applier then applies 

illustrates a transaction Tl which includes update Ul to this journal entry (JE3) to record R3. 

record RL This results in a journal entry (JE1) which is Finally, at reference numeral 15*, a commit operation for 

coupled to the backup receiver. The backup receiver sends transaction Tl has occurred. This results in a journal entry 

an acknowledgement to the primary database and deposits (JE4) which is coupled to the backup receiver. The backup 

this journal entry (JE1) in a local journal. The journal entry receiver then sends an acknowledgement to the primary 

(JE1) is then stored within a buffer by the backup applier. database and deposits this journal entry (JE4) in the local 

Next, as illustrated at reference numeral 152, transaction journal. The backup applier then releases records Rl and R3, 

T2 occurs which includes an update U2 to record R2. This maintaining the serializability of this portion of the 

results in a journal entry (JE2) which is coupled to the transaction, as required. 

backup receiver. The backup receiver then sends an ^ Finally, referring to FIG. 10, there is depicted a logic flow 

acknowledgement to the primary database and deposits this which occurs in response to an update to a record within the 

journal entry (JE2) in a local journal. This journal entry is primary database in a replica database which has been set to 

then stored within a buffer by the backup applier, as above. consistency level "Level 2" wherein serializability is not 

At reference numeral 154, the occurrence of transaction required. As above, at reference numeral 150 the occurrence 

Tl is illustrated which includes an update U3 to record R3. 45 of a transaction Tl which includes an update Ul to record 

This results in a journal entry (JE3) which is coupled to the Rl is illustrated. This results in a journal entry (JE1) which 

backup receiver. An acknowledgement is transferred from is coupled to the backup receiver. The backup receiver then 

the backup receiver to the primary database and the journal locks record Rl and sends an acknowledgement to the 

entry ( JE3) is stored within a local journal. As above, journal primary database. The journal entry (JE 1 ) is then deposited 

entry (JE3) is then stored within a buffer by the backup 50 within a local journal. The backup applier then applies the 

applier- journal entry (JE1) and immediately releases record Rl. 

Finally, a commit operation for transaction Tl occurs, as sin ce serializability is not rajuiredL 

depicted at block 156. This results in a journal entry (JE4) Next, as illustrated at block 152, a transaction T2 has 

which is coupled to the backup receiver. The backup occurred which includes an update U2 to record R2. This 

receiver then locks records Rl and R3 and sends an 55 results in a journal entry (JE2) which is coupled to the 

acknowledgement to the primary database. Thereafter, the backup receiver. The backup receiver then locks record R2 

backup applier retrieves the journal entries for transaction and sends an acknowledgement to the primary database. The 

Tl and applies the first journal entry (JE1). Record Rl is journal entry (JE2) is then deposited within the local journal, 

then released. Next, the second journal entry for transaction The backup applier then applies the journal entry (JE2) and 

Tl (JE3) is applied to record R3 and that record is released, 60 releases record R2. 

In contrast to the logic flow depicted within FIG. 7, it should Next, as depicted at block 154, a subsequent portion of 

be noted that since senahzability is not required within this transaction Tl which includes update U3 to record R3 

logic flow each record is released after its update has been occurs. This occurrence results in a journal entry (JE3) 

applied, which is coupled to the backup receiver. The backup 

Next, with reference to FIG. 9, there is illustrated a logic 65 receiver then locks record R3 and sends an acknowledge- 

flow which depicts the response of a replica database to the ment to the primary database. The journal entry ( JE3 ) is then 

updating of a corresponding record within the primary deposited within the local journal and the backup applier 
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then applies the journal entry (JE3 > and releases record R3. 
As should be apparent to those skilled in the art upon 
reference to this description, since serializability is not 
required with this Jevel of consistency, the updates to records 
Rl and R3 are imposed and each record is released imme- 
diately after imposition of that update. 

Finally, referring to reference numeral 156. a commit 
operation to transaction Tl has occurred. This results in a 
journal entry {TEA) which is coupled to the backup receiver. 
The backup receiver then sends an acknowledgement of this 
journal entry and deposits the journal entry (JE4) within the 
local journal. 

Upon reference to the foregoing those skilled in the art 
will appreciate that the method and system of the present 
invention permits a user or system operator to select an 
arbitrary consistency level for a replica database within a 
backup server from a wide spectrum of consistency levels 
which naturally include a trade-off between consistency and 
performance. A minimum level of consistency is provided 
which permits the reading of old and uncommitted values at 
one replica database while a maximum level is also possible 
within a second replica of the primary database which will 
return results as though the query were reading from the 
primary database. In this manner the efficiency of access to 
a database within a resilient database system such as the one 25 
described herein is greatly enhanced. 

While the invention has been particularly shown and 
described with reference to a preferred embodiment, it will 
be understood by those skilled in the art that various changes 
in form and detail may be made therein without departing 
from the spirit and scope of the invention. 

We claim: 

1. A method for enhanced efficiency in database access 
within a distributed data processing system, said method 
comprising the steps of: 

designating a selected database within said distributed 
data processing system as a rjrimary database, said 
selected database having a plurality of records stored 
therein; 

replicating said primary database at at least two physical 
locations within said distributed data processing sys- 
tem; 

specifying a plurality of diverse consistency levels which 
may be maintained between said primary database and 45 
each of said replicated databases; 
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permitting a user to specify a different one of said 
plurality of diverse consistency levels for query trans- 
actions against each of said replicated databases: and 
thereafter, automatically maintaining said specified one of 
said plurality of diverse consistency levels between 
said primary database and each of said replicated 
databases in response to updates to records within said 
primary database wherein queries requiring less than a 
full consistency level may be applied to a replicated 
database maintained at less than a full consistency 
level. 

2. The method for enhanced efficiency in database access 
within a distributed data processing system according to 
claim 1 . further including the step of replicating said primary 
database at a third physical location within said distributed 
data processing system. 

3. A system for enhanced efficiency in database access 
within a distributed data processing system, said system 
comprising: 

a primary database within said distributed data processing 
system, said primary database having a plurality of 
records stored therein; 

a replica of said primary database stored at at least two 
physical locations within said distributed data process- 
ing system; 

means for specifying a plurality of diverse consistency 
levels which may be maintained between said primary 
databases and each of said replicated databases; 

means for permitting a user to specify a different one of 
said plurality of diverse consistency levels for query 
transactions against each of said replicated databases; 
and 

means for automatically maintaining said specified one of 
said plurality of diverse consistency levels between 
said primary database and each of said replicated 
databases in response to updates to records within said 
primary database wherein queries requiring less than a 
full consistency may be applied to a replicated database 
maintained at less than a full consistency. 
4. The system for enhanced efficiency in database access 
within a distributed data processing system according to 
claim 3, further including a second replica of said primary 
database stored at a third physical location within said 
distributed data processing system. 
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